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^3 3 anyone of the patent document or the patent disclosure, as it appears in the Patent and 

y 4 Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. 
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1 BACKGROUND OF THE INVENTION 

2 
3 

4 1. Field of the Invention 

5 

6 The present invention relates in general to computer file systems, and more particularly 

7 to an extensible file access method for accessing a foreign file system from a data processing 

8 system with a native file system, said foreign file system and said native file system 

9 implementing different file system protocols. 
10 

1 1 
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1 

2 2. Description of the Related Art 

3 

4 A file system comprises the logical structures and software function routines used to 

5 store, organize, and access information stored on a computer system's logical or physical 

6 storage media, such as a diskette, hard disk system, or optical storage. A variety of file systerns 

7 have been developed to address various needs. For example, personal computer file systems 

8 comprise: File Allocation Table (FAT); Virtual FAT (VFAT); 32-Bit FAT (FAT32); New 

9 Technology File System (NTFS); and High Performance File System (HPFS). File systems for 
10 mid-range computers comprise: Unix File System (UFS), Network File System (NFS), and 

1 I AS/400. Mainframe computer file system offerings comprise: Virtual Storage Access Method 

,42 (VSAM ); Sequential Access Method (SAM); Partitioned Data Set (PDS); and Object Access 

^fl3 Method (OAM). File systems are not limited to these lists which are merely illustrative subsets 

'-vJ4 of the numerous variety of file systems. 

•^1 6 The various computer architectures and computer operating systems may use different 

iii 17 file systems, thus organizing and accessing the information in different ways. Generally, these 

5^1 8 different file systems are incompatible, meaning that files created by one file system may not 

^-^19 be accessed by another file system.. A user may have a computer system supporting a 

j320 particular file system, a native file system, and the user may wish to access and use information 

2 1 stored in a file system other than the native file system, a foreign file system. The user may 

22 need to access the foreign file system information for any of a number of motivations, such as 

23 to migrate the information to a replacement system, to archive the information, or to share the 

24 information among different systems. 
25 

26 Conventional systems have addressed this user need to access foreign file systems in a 

27 number of ways. The earliest conventional approach was to create a duplicate of the 

28 information and to convert the information in this duplicate from the native file system format 

29 to the foreign file system format. This approach is exemplified by patents such as U. S. Patent 
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1 Number 5,537,592, "System and Method for Reading and Writing Disks Formatted for an 

2 Operating System Foreign to the Host Computer;" U. S. Patent Number 5,742,8 1 8, "Method 

3 and System of Converting Data from a Source File System to a Target File System;" Japan 

4 Patent Number 923 II 14A, 'Tile System Conversion System;" and "Japan Patent Number 

5 6243020A, "File Conversion Device." U. S. Patent Number 5,537,592 is representative of this 

6 approach, and in particular teaches a set of processes and data structures that allow transfer of 

7 user specified files between differently formatted disks. The processes identify the file format 

8 of the source and destination disks, retrieve the source files in the source file format, store the 

9 source files in a common format in memory that allows the directory hierarchy of the source 

10 disk and destination disk to be maintained, translate the contents of text source file records to 

1 1 the record format of the destination file system if desired, create directories and headers if 

|42 necessary for the foreign disk for -the transferred files, and store the files on the destination disk 

;y 3 in a host file format. The user can then access and modify the files in the host file format using 

]H4 a host computer system. This approach is only a partial solution in that it only converts and 

rt5 reformats. the information, it does not convert the software functions. The native file system 

>j6 can still only access information stored in the native file system format; it cannot access 

]M7 information stored in the foreign file system format, nor can it use the foreign file system 

8 software functions. 
139 

Another conventional solution is to install and support both file systems on the same 

21 computer system., effectively making the foreign file system an additional native file system. 

22 This solution is taught by U.S. Patent Number 5,363,487, "Method and System for Dynamic 

23 Volume Tracking in an Installable File System," which permits a single operating system to 

24 access a storage medium formatted in accordance with differing file systems. Generally, the 

25 operating system identifies which of a plurality of file system drivers is appropriate for reading 

26 a particular storage volume and, thereafter, associates the identified file system driver with the 

27 particular storage volume. Similarly, U. S. Patent Number 5,91 1,776, "Automatic Format 

28 Conversion System and Publishing Methodology for Multi-user Network," provides a set of 

29 multiple shadow file converters connected to a source file of an original document. Each 
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1 shadow file converter enables the transformation of the original source file format into a 

2 particular other specific type of file format. However, providing all the permutations of the 

3 different types of file systems ported to the different types of operating systems and computer 

4 hardware architectures is probably not commercially feasible. 
5 

6 ' A more robust conventional approach is to directly convert file system requests from 

7 one file system protocol to another. For example, a client system, having a native file system 

8 protocol, may issue a request in the client's native file system protocol to a server. However, 

9 the server uses a foreign file system protocol which is different form the client's native file 
10 system protocol. A file system protocol converter translates the client's request from the 

1 1 client's native file system protocol to the server's foreign file system protocol. The file system 

|4.2 converter may also convert the server response by reformatting the response's information from 

:3{3 the server's foreign file system format to the client's native file system format. This type of 

direct file system protocol conversion is taught by: U. S. Patent Number 5,218,697, ''Method 

1^5 and System for Networking Computers Having Varying File Architectures;" U. S. Patent 

6 Number 5,752,005, "Foreign File System Establishing Method which Uses a Native File 

M7 System Virtual Device Driver;" U. S. Patent Number 5,937,406, "File System Interface to a 

|1 8 Database;" U. S. Patent Number 5,864,853, "Portable File System Operable Under Various 

,:;tI9 Computer Environments;" and U, S. Patent Number 4,956,809, "Method for Canonical 

J^O Ordering of Binary Data for Portable Operating Systems." Foreign patents representative of 

2 1 this approach include: Japan Patent Number 1 0247 1 55A, "File System Interface for Data 

22 Base;" Japan Patent Number 8 1 37728A, "Portable File System and File Data Processing 

23 Method;" Japan Patent Number 7230396A, "Mutual Constitution System for Different Kinds 

24 of File System Forms;" and Japan Patent Number 1 0260877 A, "Protocol Conversion System in 

25 Client Server System, Method Therefor and Recording Medium Programmed and Recorded 

26 with the Method." Publications of this approach include: "File Interface for Migrating 

27 Applications to Enhanced Persistent Storage Platforms," IBM Technical Disclosure Bulletin, 

28 June 1992, p. 182-183; "AS/400 OS/2 PC Support Shared Folders," id., Dec. 1989, p. 202- 

29 205; "Method to Manage the Mapping of Logical to Physical Record," id., Dec. 1995, p. 261- 
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1 262; 'Implicit Mapping of File Data," id., April 1995, p. 523-524; and "OS/2 Logical File 

2 System," id.. May. 1992, p. 370-37 1 . Although this approach is a significant improvement 

3 over merely converting the information format, it still suffers from the disadvantage of even 

4 more permutations, where the permutations for each converter for a different pair of source and 

5 target file systems ported to the different types of operating systems and computer hardware 

6 architectures is also probably not commercially feasible. 
7 

8 Thus, there is a clearly felt need for a method, system and computer program product 

9 for providing an improved extensible file access method for accessing a foreign file system 

10 from a data processing system with a native file system, said foreign file system and said native 

1 1 file system implementing different file system protocols. 
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I SUMMARY OF THE INVENTION 

2 

3 The present invention comprises an extensible file access method for accessing a first 

4 foreign file system from a data processing system with a first native file system, said first 

5 foreign file system and said first native file system implementing different file system 

6 protocols. 
7 

8 In accordance with an aspect of a preferred embodiment of the present invention, an 

9 extensible file access method for accessing a foreign file system from a data processing system 
10 with a native file system, said foreign file system and said native file system implementing 

1 1 different file system protocols, comprises the steps of: 
sJ2 issuing a request according to the native file system protocol for data stored in the 

:fl3 foreign file system; 

'J4 translating the native file system request to an intermediate programming interface, 

jJS wherein the intermediate programming interface is different from both the native file system 

•d 6 protocol and the foreign file system protocol; 

•:J 7 translating the intermediate file system request to the foreign file system protocol; and 

ifl 8 returning to the data processing system a response from the foreign file system 

9 responsive to the translated request. 

2 1 In accordance with another aspect of a preferred embodiment of the present invention, 

22 the extensible file access method is extended to support a second foreign file system by 

23 determining the second foreign file system protocol and by providing a translation from the 

24 intermediate programming interface to the second foreign file system protocol. 
25 

26 In accordance with another aspect of a preferred embodiment of the present invention, 

27 the extensible file access method is extended to support a second native file system by 

28 determining the native file system protocol and by providing a translation from the second 

29 native file system protocol to the intermediate programming interface. 
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1 In accordance with another aspect of a preferred embodiment of the present invention, 

2 the intermediate programming interface comprises a set of generic access functions common to 

3 the native file system protocol and the foreign file system protocol, and comprises a set of file 

4 system specific functions which are not common to the file system protocols. 
5 

6 In accordance with another aspect of a preferred embodiment of the present invention, 

7 the set of generic access functions common to the native file system protocol and the foreign 

8 file system protocol are translated from the native file system protocol to the intermediate 

9 programming interface which is then translated to the foreign file system protocol, and the set 

10 of file system specific functions which are not common to the file system protocols are not 

1 1 translated from the native file system protocol to the intermediate programming interface. 

jy 3 In accordance with another aspect of a preferred embodiment of the pi'esent invention, 

jJ4 the set of file system specific functions which are not common to the file system protocols 

; -J 

N 5 further comprises a set of extended native file system functions which have no equivalent 

m 

6 function in the foreign file system protocol. 
M7 

fjil 8 In accordance with another aspect of a preferred embodiment of the present invention, 

r - 3 

J^'19 the set of extended native file system functions causes a predetermined response to be sent to 

QlO the data processing system. 

22 In accordance with another aspect of a preferred embodiment of the present invention, 

23 the set of file system specific functions which are not common to the file system protocols 

24 further comprises and a set of extended foreign file system functions which have no equivalent 

25 function in the native file system protocol. 
26 

27 In accordance with another aspect of a preferred embodiment of the present invention, 

28 the set of extended foreign file system functions are passed through to the foreign file system in 

29 an untranslated form. 
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A preferred embodiment of the present invention has the advantage of providing a 
method for integrating existing appHcations which use a native file system with back-end data 
management systems which use a separate foreign file system. 

A preferred embodiment of the present invention has the advantage of allowing an 
application written for the native file system to read and write data to a back-end application or 
back-end data store without requiring file system modifications of that application. 

A preferred embodiment of the present invention has the advantage of allowing the 
native file system application to create, view and manipulate the meta-data for the back-end 
application from the native file system application. 

A preferred embodiment of the present invention has the advantage of allowing the 
foreign file system application to appear as if it is written to the native file system. 

A preferred embodiment of the present invention has the advantage of allowing the 
native file system application to access the foreign file system as if it is a native file system. 

A preferred embodiment of the present invention has the advantage of reducing the 
complexity of supporting an additional native file system. 

A preferred embodiment of the present invention has the advantage of reducing the 
complexity of supporting an additional foreign file system. 

A preferred embodiment of the present invention has the advantage of reducing the 
complexity of translating from multiple native file system protocols to multiple foreign file 
system protocols. 

A preferred embodiment of the present invention has the advantage of allowing the 
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1 native file system application by use of the virtual file system to seamlessly access statically 

2 stored files (such as File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), 

3 hierarchical data base files, relational data base files, and object oriented database files) and 

4 dynamically constructed files (such as Information Management System (IMS) transactions or 

5 Customer Information Control System (CICS) transactions). 
6 

7 A preferred embodiment of the present invention has the advantage of providing a 

8 consistent and potentially standard method for accessing back-end storage systems. 
9 

1 0 A preferred embodiment of the present invention has the advantage of providing a 

1 1 unified storage access model which allows native file system applications and the native 
|42 operating system to seamlessly import and export data to back-end server systems via the 

'^3 virtual file system by presenting the back-end systems in a way as to be indistinguishable from 

■^^14 the local file system. 

II J 

§ i 
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1 BRIEF DESCRIPTION OF THE DRAWINGS 

2 

3 For a more complete understanding of the present invention and the advantages thereof, 

4 reference is nov^ made to the Description of the Preferred Embodiment in conjunction with the 

5 attached Drawings, in which: 
6 

7 Figure 1 is a block diagram of a distributed computer system which may be used in 

8 performing the method of an embodiment of the present invention, forming part of the 

9 apparatus of an embodiment of the present invention, and which may use the article of 

10 manufacture comprising a computer-readable storage medium having a computer program 

1 I embodied in said medium which may cause the computer system to practice an embodiment of 

;42 the present invention; 

}■=¥ 

H4 Figure 2 is a block diagram of an architecture of a preferred embodiment of the present 

|35 invention; and 

^6 

Hi 17 Figures 3 and 4 are flowcharts illustrating the operations preferred in carrying out a 

|fl 8 preferred embodiment of the present invention. 
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1 DESCRIPTION OF THE PREFERRED EMBODIMENT 

2 

3 Referring first to Figure 1, there is depicted a graphical representation of a data 

4 processing system 8, which may be utilized to implement the present invention. As may be 

5 seen, data processing system 8 may include a plurality of networks, such as Local Area 

6 Networks (LAN) 10 and 32, each of which preferably includes a plurality of individual 

7 computers 12 and 30, respectively. Of course, those skilled in the art will appreciate that a 

8 plurality of Intelligent Work Stations (IWS) coupled to a host processor may be utilized for 

9 each such network. Each said network may also consist of a plurality of processors coupled via 

10 a communications medium, such as shared memory, shared storage, or an interconnection 

1 1 network. As is common in such data processing systems, each individual computer may be 
|42 coupled to a storage device 14 and/or a printer/output device 16 and may be provided with a 
'M3 pointing device such as a mouse 17. 

p5 The data processing system 8 may also include multiple mainframe computers, such as 

ji6 mainframe computer 18, which may be preferably coupled to LAN 10 by means of 

JLJ7 communications link 22. The mainframe computer 18 may also be coupled to a storage device 

n 8 20 which may serve as remote storage for LAN 10. Similarly, LAN 10 may be coupled via 

E X : 

iJ9 communications link 24 through a sub-system control unit/communications controller 26 and 

] JO communications link 34 to a gateway server 28. The gateway server 28 is preferably an IWS 

2 1 which serves to link LAN 32 to LAN 10. 

22 

23 With respect to LAN 32 and LAN 10, a plurality of documents or resource objects may 

24 be stored within storage device 20 and controlled by mainframe computer 18, as resource 

25 manager or library service for the resource objects thus stored. Of course, those skilled in the 

26 art will appreciate that mainframe computer 18 may be located a great geographic distance 

27 from LAN 10 and similarly, LAN 10 may be located a substantial distance from LAN 32. For 

28 example, LAN 32 may be located in California while LAN 10 may be located within North 

29 Carolina and mainframe computer 18 may be located in New York. 
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1 Software program code which employs the present invention is typically stored in the 

2 memory of a storage device 14 of a stand alone workstation or LAN server from which a 

3 developer may access the code for distribution purposes, the software program code may be 

4 embodied on any of a variety of known media for use with a data processing system such as a 

5 diskette or CD-ROM or may be distributed to users from a memory of one computer system 

6 over a network of some type to other computer systems for use by users of such other systems. 

7 Such techniques and methods for embodying software code on media and/or distributing 

8 software code are well-known and will not be further discussed herein. 
9 

10 As will be appreciated upon reference to the foregoing, it is often desirable for a user 

1 1 working on a workstation 12 to be able to access information or files stored on host storage 
.rjL2 device 20 on the host 1 8. Such files are usually stored on host storage device 20 in accordance 

;IP3 with a host file system protocol which is different from the workstation file system protocol 

yj 

^-1|4 used to store files on the workstation 12. The present invention provides an extensible file 

ill 

jj5 access method and virtual file system which allows an application executing on the workstation 

'•:|6 12, having a native file system for files stored on the workstation 12, to access files stored on 

-17 the host storage device 20, the host storage files being stored in a foreign file system 

f|f 8 implementing a different file system protocol from the workstation or native file system 

fi9 protocol. 

m 

21 Referring next to Figure 2, there is shown a block diagram of an architecture of a 

22 preferred embodiment of the present invention. The foreign file system 20 is accessed by 

23 issuing a request according to the native file system protocol 285 for data stored in the foreign 

24 file system 20; translating the native file system request to an intermediate programming 

25 interface 250, wherein the intermediate programming interface 250 is different from both the 

26 native file system protocol 285 and the foreign file system protocol (255, 260, or 265); 

27 translating the intermediate file system request to the foreign file system protocol; and 

28 returning to the data processing system a response 295 from the foreign file system responsive 

29 to the translated request. Multiple foreign file systems 235 and 240 may be supported by 
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1 determining a second foreign file system protocol and by providing a translation from the 

2 intermediate programming interface to the second foreign file system protocol. Also, multiple 

3 native file systems may be supported by determining a second native file system protocol and 

4 by providing a translation from the second native file system protocol to the intermediate 

5 programming interface. 
6 

7 The intermediate programming interface comprises a set of generic access functions 

8 common to the native file system protocol and the foreign file system protocol and a set of file 

9 system specific functions which are not common to the file system protocols. The set of 

10 generic access functions common to the native file system protocol and the foreign file system 

1 1 protocol are translated from the native file system protocol to the intermediate programming ' 
^4,2 interface which is then translated to the foreign file system protocol, and the set of file system 
'53 specific functions which are not common to the file system protocols are not translated from 

the native file system protocol to the intermediate programming interface which is then 

A5 translated to the foreign file system protocol. Existing applications which use a native file 

•lf6 system may be more easily integrated with back-end data management systems which use a 

separate foreign file system without requiring file system modifications of the existing 

1^ 8 application. A foreign file system application may appear as if it is written to the native file 

p9 system, and a native file system application may access the foreign file system as if it is a 

120 native file system. A dynamic virtual file system may be constructed to support a consistent 

21 standard interface to seamlessly access statically stored files and dynamically constructed files. 
22 

23 Sash 200 is a replacement for a conventional Common Internet File System (CIFS) 

24 server. It consists of a Server Message Block (SMB) server 210 which interfaces to a client 

25 215, and one or more FSModule backends 220, 225, and 230 which interface on one side to 

26 the SMB server 210 and on the other side to the backends 235, 240, and 245. The SMB server 

27 210 includes the server itself, the logging system and the control file that manages the SMB 

28 server. The design and implementation of the SMB server is based on an Internet-Draft, A 

29 Common Internet File System (CIFS) Protocol, 
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1 http://msdn.microsoft.com/workshop/networking/cifs/default.asp. 

2 

3 

4 The backend, FFSModule 220, exposes ISash 250 which is a Common Object Model 

5 (COM) interface to communicate with the SMB server. The FFSModule receives requests 

6 from the SMB server through ISash, translates them to appropriate application programming 

7 interfaces (APIs) 255, 260, and 265 provided by client-API dynamic link libraries (dils). The 

8 FFSModule then returns the pertinent information to the SMB server. 
9 

10 A COM interface, ISash 250, defines the intermediate programming interface between 

1 1 the SMB 210 and the FFSModule 220, 225, and 230 . The ISash interface comprises disk 
1=42 type calls and is described in Table A. 

'"44 FFSModule is a COM object. When the network command "net use devicename: 

5 WSMBservernameVsharename" 270 is issued, the SMB 210 creates a new instance of 

6 FFSModule object 220 associated with the given sharename 275 and acquires the ISash 

17 interface pointer. The "SMBservername" 280 is the name of the SMB server, and "sharename" 

Lrt 8 275 is a system name or a dataset name provided by a user. After SMB gets the ISash pointer, 

jTI9 it sends the first request to FFSModule to mount the sharename to a drive letter. Once a system 

J=^0 235 or a data set is mounted, it is simply treated as if it was a local native file system drive. 
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1 The following Table A is the list of requests that can come into SMB (a native file 

2 system protocol), the translated request (intermediate programming interface) to FFSModule 

3 from SMB, and the translated API calls made by FFSModule (foreign file system protocol) to 

4 obtain the necessary data from the file system, an MVS file system in this example: 
5 

6 . 

7 TABLE A 

8 Client to SMB Interface SMB to ISash Interface ISash to MVS 

9 SMB Call ISash Call MVS Call 
10 

1 1 SMB_COM_CHECK_DIRECTORY CheckDirectory CheckDirectory(BSTR InDirName, BYTE Is8p3, 

1 2 SashlDUnit uid, SashlDUnil pid, BSTR 

1 3 *OutDirName, BYTE *DoesExist) 
|44 DirectoryListing * 

M|5 DirectoryListing::getListing(*m_pHost, Qualifier); 

f%6 new DirectoryListing: :Cursor(**ppDirLisl, 

i1j7 CsrPattern); 

;r!8 DirectoryListing: :Cursor::setToFirst(); 

r. 

M 9 DirectoryListing::Cursor::isValid(); 
"1^20 DirectoryListing: :Cursor: :element(); 

=12 1 unsigned char FFSFileItem::isDirectory() 

m 

J53 SMB_COM_CLOSE CloseFile CloseFiie( SashFid Fid, BYTE Flags, SHORT 

UQ-A Options ) 

25 The file object created at open time will be deleted. 

26 

27 SMB„C0M_CREATE__D1RECT0RY CreateDirectory CreateDirectory(BSTR NewDirectory, SashlDUnit 

28 TRANS2_CREATE_DIRECT0RY uid, SashlDUnit pid ) 

29 Not supported. 
30 

3 1 SMB_COM_DELETE DeleteFile DeleteFiIe( BSTR FileName, SashFileAttributes 

32 FileAttributes, SashlDUnit uid, SashlDUnit pid ) 

33 FFSConnecledDrive * 

34 HostSystem::returnConnection(0, FALSE); 
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1 Result * 

2 FFSConnectedDrive::deleleFile(SlashNaine); 
3 

4 SMB_QUERY_FILE_BASICJNFO FileAltributes FileAttributes( BSTR FileName, SHORT Options, 

5 SMB_INFO_STANDARD SashFileAttributes InAttributes, SashDate InDate, 

6 SMBJNFO_QUERY_EA_SIZE SashTime InTime, SashlDUnit uid, SashlDUnit 

7 SMB_INFO_QUERY_EAS_FROM_LlST pid, LONG *OutSize, 

8 SMBJNFO_QUERY„ALL_EAS SashFileAttributes *OutAttributes, 

9 SMB JNFOJS_NAME_VALID SashDate *OutDate, SashTime *OutTiine ) 
1 0 TRANS2_QUERY_PATH JNFORM ATION 

1 1 SMB_QUERY_FILE_STANDARDJNFO 

1 2 SMB_QUERY_FILE„EA_INFO 

1 3 SMB_QUERY_FILE_NAMEJNFO 

14 SMB COM SET INFORMATION 

_ _ _ 

:j5 TRANS2_SET_PATH_INF0RMAT10N 

m 

l=|7 TRANS2_SET_PATHJNFORM ATION FileDateTime FileDateTime( SashFid Fid, BYTE Flags, 

□ 8 SMBJNFO_STANDARD SashDate InDate, SashTime InTime, 

SiV1B_INF0_QUERY_EA_SIZE SashDate *OutDate, SashTime *OutTime ) 

s:'20 Not called by SMB 

S' 

T^2 SMB_COM_FIND_CLOSE, FIND_CL0SE2 FindFileClose 

lis 

.54 SMB_C0M_F1ND FindFirstPile FindFirstFile( BSTR SearchPattern, 

25 TRANS2_FIND_F1RST2 SashFileAttributes SearchAltributes, 

26 SMB_FIND_FILE_FULL_DIRECTORYJNFO SashlDUnit uid, SashlDUnit pid, 

27 SMB_FTND_FILE_BOTH_DIRECTORY_INFO BSTR *FileName, BSTR *ShortFileName, 

28 SashDate *CreationDate, 

29 SashTime *CreationTime, 

30 SashDate *LastAccessDate, 

3 1 SashTime *LastAccessTime, 

32 SashDate *LastModiryDate, 

33 SashTime *LastModif*yTime, 

34 SashFileAttributes *FileAttributes, 

35 LONG *Size, FindHandle *hFind ) 
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1 DirectoryLisling * 

2 DirectoryLisling: :getListing(*m_pHost, Qualifier) 

3 new DircctoryListing::Cursor(**ppDirList, 

4 CsrPatlern) 

5 DirectoryListing::Cursor::selToFirst() 

6 DirectoryLisling: :Cursor::isValid() 

7 DirectoryLisling: :Cursor::elemenl() 

8 unsigned char FFSFileIlem::isFiIe() 

9 const FFSFile & FFSFileItem::asFile() 

10 const FFSFile & FFSFileIlem::asDirectory() 

1 1 FFSTimeSlamp::year() 

1 2 FFSTimeSlamp::monlh() 

13 FFSTimeSlamp::day() 
^^4 FFSTimeSlamp::hour() 

FFSTinieSlamp::minute() 
FFSTi meSlamp: :second() 

Q 8 SMB_COM_FIND FindNexlFile FindNexlFile( FindHandle hFind, BYTE Flags, 

9 TRANS2_F1ND_FIRST2 BSTR *FileName, BSTR *ShortFileName, 

,:'20 TRANS2_FIND_NEXT2 SashDate *CrealionDale, 

1 SashTime '^CreationTime, 

1^2 SashDate * Last Access Dale, 

^^3 SashTime *LaslAccessTime, 

• J4 SashDate *LastModilyDate, 

25 SashTime *LaslModityTime, 

26 SasliFileAttribules *FileAttributes, 

27 LONG *Si2e ) 

28 DirectoryLisling: :Cursor::selToNext(); 

29 DirectoryLisling::Cursor::isValid() 

30 DirectoryListing::Cursor::elemenl().isFile() 
3 I const FFSFile & FFSFileIlem::asFile() 

32 const FFSFile & FFSFileIlem::asDireclory() 

3 3 FFSTi meS lamp: : year() 

34 FFSTi meSlamp::monlh() 

3 5 FFSTi meS lamp : : day ( ) 
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2 
3 
4 
5 
6 
7 
8 
9 
10 
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SMB_COM_FLUSH 



FlushVoIume 



Not applicable 



GetCustomlnterface 



FFSTiineStainp::hour() 

FFSTimeStamp::minule() 

FFSTimeSlamp::second() 

FlushVolume( BYTE Flags, 
SashlDUnit uid, SashlDUnit pid) 
FFSFileFile::flush(); 

GetCustomInterface( BSTR Path, lUnknown 
**pIUnknown ) 

This call is currently not used. It will be 
inplemented if necessary. 



TRANS2_QUERY_FILE__lNFORMATION GetFilelnfo GetFileInfo( SashFid Fid, BSTR *FileName, 
BSTR 

*ShortFileName, 

BSTR *Path, 

SashDate *CreationDate, 

SashTime *CreationTime, 

SashDate *LastAccessDate, 

SashTime *LastAccessTime, 

SashDate *LastModifyDate, 

SashTime *LastModityTime, 

SashFileAttributes *FileAttributes, LONG *Size ) 

FFSFileFile::createdTime()->year() 

FFSFileFile::createdTime()->month() 

FFSFileFile::createdTime()->day() 

FFSFileFile::createdTime()->hour() 

FFSFileFile::createdTime()->minute() 

FFSFileFile::createdTime()->second() 

FFSFileFile::lastReadTime()->year() 

FFSFileFile::lastReadTime()->month() 

FFS Fi leFi le: : lastReadTi me()->day() 

FFS Fi leFi le: : lastReadTi me()->hour() 

FFSFi leFi le: : lastReadTi me()->mi nute() 
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1 FFSFileFile::lastReadTime()->second() 

2 FFSFi leFi le: : I aslModi fiedTi me()->year() 

3 FFSFileFile::lastModifiedTime()->month() 

4 FFSFileFile::lastModifiedTimc()->day() 

5 FfSFi!eFile::lastModifiedTime()->hour() 

6 FileFile::lastModifiedTime()->minule() 

7 FFSFileFile::laslModifiedTime()->second() 

8 FFSFileFile::length(); 
9 

1 0 SMB_QUERY_FS_SIZE_INFO GelFSFreeSpace GetFSFreeSpace( BSTR FSName, 

1 1 TRANS2_QUERY_FSJNFORMATION SashlDUnit uid, SashlDUnit pid, 

1 2 LONG *SeclorsPerClusler, 

1 3 LONG *BytesPerSector, 

, J 4 LONG *NumOtPreeClusters, 

3 5 ' LONG *TotalNumberOrciusters ) 

P=i6 This call is not applicable to MVS. Provide 

=|J 7 dummy data to satisf y SMB. 

O 8 *SectorsPerCluster =^ 256; 

9 *BytesPerSector = 256; 

20 *NumOtFreeC!usters = 126; 

!^ 1 *TotalNumberOrciusters = 4096; 

bp 

i^23 Not applicable Init Init( BSTR Paths, BYTE *UseCompletePath ) 

FFSControl : : loadSystemXML(); 

25 HostSystem * 

26 FFSControl : :getSystem(ServerName); 
27 

28 SMB_COM_OPEN OpenFile OpenFile(BSTR FileName, SashFileAttributes 

29 SMB_COM_CREATE Attribs, SHORT Options, BYTE Flags, 

30 SMB_COM_NT_CREATE_ANDX SashlDUnit uid, SashlDUnit pid, SHORT 
3 I *Resuh, SashFid *Fid) 

32 DirectoryListing * 

33 DirectoryListing: :getListing(*m_pHost, Qualifier); 

34 new DirectoryListing;:Cursor(**ppDirList, 

35 CsrPatlern); 
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1 DirectoryLisling::Cursor::setToFirst(); 

2 DirectoryLisling::Cursor::isValid(); 

3 DirectoryListing::Cursor::element{); 

4 unsigned char FFS Fi lei tern: :isDirectory() 

5 new 

6 FFSFileDirectory(SlashName,Atlr,ni_pCurrentHost); 

7 new 

8 FFSFileFile(SIashName,Atlr,m_pCurrentHost); 

9 FFSFileFiIe::flush(); 
10 

I 1 SMBJNFO_VOLUME QueryVolumelnfo QueryVolumeInfo( SashlDUnit uid, SashlDUnit 

1 2 TRANS2_QUERY_FS ^INFORMATION pid, BSTR * VolumeName, 

13 SMB„QUERY_FS_VOLUMEJNFO LONG *VolumeSerialNumber) 

J 4 SMB_COM_QUERY JNFORMATION_DISK This call is not applicable to MVS. Provide 

?d 5 dummy data to satisfy SMB. 

W6 

1^ 7 SMB_COM_READ Read Read( SashFid Fid, LONG Of fset, LONG Count, 

Q 8 SMB_COM_LOCK„AND_READ SAFEARRAY **buf, LONG *BytesRead ) 

■g 9 SMB_COM_READ_RAW FFSFileFile::get(Ofl^set,Count); 

20 SMB_COM_READ_MPX 

ft 1 SMB_COM_READ_ANDX 

1 j23 SMB_COM_DELETE_DIRECTORY Re move Directory RemoveDirectory(BSTR Directory, 

1^24 SashlDUnit uid, SashlDUnit pid) 

25 Not supported. 

26 

27 SMB_COM_RENAME Rename Rename( BSTR OldFileName, 

28 SMB_COM_NT_RENAME SashFileAttributes FileAttributesI , 

29 BSTR NewFileName, 

30 SashFileAttributes FileAttributes2, 

31 SashlDUnit uid, SashlDUnit pid, 

32 BYTE Reserved) 

33 FFSConnectedDrive * 

34 HostSytem::returnConnection(0,FALSE); 

35 DirectoryListing * 
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SMB COM SEEK 



Seek 



SMB_COM_TREE_DISCONNECT 
TREE_DISCONNECT 



Unlnil 



SMB_COM_LOCKING_ANDX UnlockFile 

SMB„COM_WRITE„AND_UNLOCK 

SMB_COM_TREE_DISCONNEeT 

SMB_COM_WRITE Write 
SMB_C0M_WRITE_PRINT_F1LE 
SMB_COM_WRITE_AND_UNLOCK 
Offset, 

SMB_COM_READ_RAW 

SMB_COM_WRITE_MPX 

SMB_COM_WRITE_RAW 

SMB_COM_WRITE_COMPLETE 

SMB_COM_WRITE_MPX_SECONDARY 

SMB_COM_WRITE_AND_CLOSE 



DirectoryListing::getListing(*m_pHost, 
Qualifier); 

new DirectoryLisling::Cursor(**ppDirList, 
CsrPattern); 

DirectoryListing::Cursor::setToFirst(); 
DirectoryListing::Cursor::isValid(); 
DirectoryListing::Cursor::element(); 
unsigned char FFSFileIlein::isDirectory() 
Result * FFSConnectedDrive::renameFile 
(SIashOldName,SlashNewName); 

Seek( SashFid Fid, LONG Offset, BYTE Mode, 
LONG *NewOffset ) 
FFSFileFile::seek(CurrPos + Offset); 
FFSFileFile::tell(); 
FFSFileFile::seekToEnd(); 

UnlnitO 

Destroy all the file objects created. 
Destroy all the DirectoryListing created, 

UnlockFile( SashFid Fid) 
Not called by SMB 



Write( SashFid Fid, LONG Offset, LONG Count, 
SAFEARRAY *buf, LONG *BytesWritten ) 
FFSFileFile::put((const char*)&RawBuffer, 

Count); FFSFile::seekToEnd(); 
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1 SMB_C01V1_WRITE_ANDX 

2 SMB_C0M_WR1TE_BULK 

3 SMB_C0M_WR1TE_BULK_DATA 
4 

5 

6 

7 

8 Referring now to Figure 3 and Figure 4, the flowcharts illustrate the operations 

9 preferred in carrying out the preferred embodiment of the present invention. In the flowcharts, 

10 the graphical conventions of a diamond for a test or decision and a rectangle for a process or 

1 1 function are used. These conventions are well understood by those skilled in the art, and the 

12 flowcharts are sufficient to enable one of ordinary skill to write code in any suitable computer 

1 3 programming language for an assembler, interpreter, or compiler. 

Referring first to Figure 3, after the start 310 of the process 300, a native request from a 

rj 6 client on the workstation to the remote data processing system to open a foreign file in the 

H 

=37 foreign file is generated in process block 320. Responsive to the request, process block 330 

^N8 determines the native file system protocol; and process block 340 determines the foreign file 

pi 9 system protocol. Thereafter, process block 350 translates the native file system request to an 

fjpO intermediate programming interface, wherein the intermediate programming interface is 

different from both the native file system protocol and the foreign file system protocol. Process 

^22 block 360 then translates the intermediate file system request to the foreign file system 

23 protocol. Thereafter, process block 370 issues the translated request to the foreign file system; 

24 and process block 380 returns to the client a response from the foreign file system responsive to 

25 the translated request. The process then ends at process block 390. 
26 

27 Referring now to Figure 4, process 400 is an expansion of the translation process steps 

28 340, 350, 360, and 370 of Figure 3. Decision block 410 determines if the native file system 

29 request is a common access function, an access function common to both the native file system 

30 protocol and the foreign file system protocol. If the native file system request is a common 
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1 access function, then process block 420 translates the common access function from the native 

2 file system protocol to the intermediate programming interface and then translates it from the 

3 intermediate system protocol to the foreign file system protocol. Thereafter, processing 

4 continues to process block 380 which returns the response to the client. 
5 

6 Returning now to decision block 410, if the native file system request is not a common 

7 access function, then decision block 440 determines if the native file system request is an 

8 extended native function, a native file system functions which have no equivalent function in 

9 the foreign file system protocol. If the native file system request is an extended native function, 

10 then process block 450 prepare a predetermined response to be sent to the client, preferably 

1 1 indicating the inability of the foreign file system to service the request. Thereafter, processing 
H2 continues to process block 380 which returns the response to the client. 

'''fl4 Returning now to decision block 440, if the native file system request is not an 

pi 5 extended native function, then decision block 460 determines if the native file system request is 

'^^^16 an extended foreign function, a foreign file system function which has no equivalent function 

jl^lV in the native file system protocol. If the native file system request is an extended foreign 

IJllS function, then process block 470 passes through the extended foreign function to the foreign 

^^19 file system in an untranslated form. Thereafter, processing continues to process block 380 

W20 which returns the response from the extended foreign function to the client. 
21 

22 Returning now to decision block 460, if the native file system request is not an 

23 extended foreign function, then process block 480 returns an error to the client as the request 

24 was neither a common, extended native, nor extended foreign function. 
25 

26 Using the foregoing specification, the invention may be implemented using standard 

27 programming and/or engineering techniques using computer programming software, firmware, 

28 hardware or any combination or sub-combination thereof. Any such resulting program(s), 

29 having computer readable program code means, may be embodied within one or more 
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computer usable media such as fixed (hard) drives, disk, diskettes, optical disks, magnetic tape, 
semiconductor memories such as Read-Only Memory (ROM), Programmable Read-Only 
Memory (PROM), etc., or any memory or transmitting device, thereby making a computer 
program product, i.e., an article of manufacture, according to the invention. The article of 
manufacture containing the computer programming code may be made and/or used by 
executing the code directly or indirectly, from one medium, by copying the code from one 
medium to another medium, or by transmitting the code over a network. An apparatus for 
making, using, or selling the invention may be one or more processing systems including, but 
not limited to, central processing unit (CPU), memory, storage devices, communication links, 
communication devices, servers, input/output (I/O) devices, or any sub-components or 
individual parts of one or more processing systems, including software, firmware, hardware or 
any combination or sub-combination thereof, which embody the invention as set forth in the 
claims. 

User input may be received from the keyboard, mouse, pen, voice, touch screen, or any 
other means by which a human can input data to a computer, including through other programs 
such as application programs. 

One skilled in the art of computer science will easily be able to combine the software 
created as described with appropriate general purpose or special purpose computer hardware to 
create a computer system and/or computer sub-components embodying the invention and to 
create a computer system and/or computer sub-components for carrying out the method of the 
invention. Although the present invention has been particularly shown and described with 
reference to a preferred embodiment, it should be apparent that modifications and adaptations 
to that embodiment may occur to one skilled in the art without departing from the spirit or 
scope of the present invention as set forth in the following claims. 
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